Tracking of persons with camera-fusion technology

The idea of a robot tracking and following a person is not new. Different combinations of laser range finders and camera pairings have been used for research on this subject. In the last years stereoscopic systems have been developed to compensate shortcomings of laser range finders or ultra sonic sensor arrays in means of 3D recognition. When Microsoft began the distribution of the Microsoft Kinect in the year 2010 they released a comparatively cheap system, that combines depth measurement and a color view in one device. Though the system was intended as a new remote controlling system for games, tackling the market launch of motion sensing wireless controllers such as the Nintendo Wiimote and Sony Playstation 3 move some developers saw more in this technology. And so it did not take long until the first hacks for the Microsoft Kinect were published after the initial release. More and more people started to create own software, ranging from shadowpuppets [TW10] to remote controlling home cinema systems [Nar11]. Microsoft and PrimeSense soon recognized the potential and released free drivers and sdks for the use of the camera device with PCs. With Prime Sense publishing the drivers as open source a lot of possible uses came up for the Microsoft Kinect. Some companies used this event to enter the market of camera-fusion technology. The most comparable system to the Microsoft Kinect is the Xtion Pro Live by Asus. These devices merging the depth measurement and color view with computation on a deviceinternal system reveal new possibilities concerning the tracking of persons and enabling them to even give the robot commands using gestures. This paper shall inquire to what extend the Microsoft Kinect or the Asus Xtion Pro Live can be used as substitute for stereoscopic cameras/laser range finder systems in context of a tracking and control device for human robot interaction scenarios with person following applications for service robots

Automatic crash dump processing

Fehler in der Software kennt jeder, der mit Computern arbeitet, zur Genüge. Manche Fehler sind lediglich ein Ärgernis für den Nutzer, andere machen die Nutzung der Software unmöglich. Diese zweite Fehlersorte äußert sich darin, dass die Software abstürzt bzw. nicht mehr weiter nutzbar ist. Um solche Fehler bei einer bereits ausgelieferten Software zu beheben, muss der Hersteller vom Auftreten des Fehlers informiert werden. Hierzu kann sich der Hersteller der Nutzung von Crash Reports bedienen. Crash Reports sind Fehlerberichte, die im Fehlerfall an den Hersteller der Software gesandt werden und Daten enthalten, die Informationen zum Absturzzustand liefern. Abhängig von der Anzahl der beim Hersteller eingehenden Fehlerberichte und der zu Verwaltung deren zugeteilten Entwickler, wird es nach einiger Zeit mühsam und vor allem zeitaufwändig, die Übersicht über bekannte Fehler zu behalten und die neu eingehenden manuell zu verarbeiten. Ziel dieser Diplomarbeit ist es, ein System zu entwickeln, das die Verarbeitung von automatisch erstellten Fehlerberichten von manueller Arbeit in einen halb-automatischen Vorgang überführt. Der Sinn liegt hierbei in der Effizienzsteigerung und Arbeitseinsparung für die Entwickler. Zur Zeit muss jeder eingehende Fehlerbericht noch von Hand manuell überprüft werden, der Fehler bzw. die fehlererzeugende Methode gefunden und danach einem bekannten Fehler im Bug-Tracking-System zugeordnet oder darin als neu klassifiziert werden. Ebenso ist es möglich, dass vergleichbare Fehler nicht als ähnlich vom Menschen klassifiziert werden, da ihnen das Wissen um den anderen Fehler fehlt und ihre subjektive Suchabfrage im Bug-Tracking-System kein Ergebnis liefert. Die Arbeit stützt sich dabei auf die bekannten Theorien und Umsetzungen für Fehlerzuordnung und soll ferner den genauen Grad der Automatisierung feststellen, der für ein System geeignet ist, das sowohl auf händisch erstellten Fehlermeldungen, als auch auf automatisch generierten Fehlerberichten basiert. Die für die Zuordnung bekannter Fehler verschiedenen bekannten Techniken sollen auf ihre Nützlichkeit hin evaluiert werden. Das nützlichste Verfahren soll dann in die Implementierung des Gesamtsystems einfließen

Data Exchange in Bauhaus

In the context of the Bauhaus project, reengineering environments to support program understanding of legacy code are being developed. Bauhaus defines two formats to represent information that has been extracted from source code. One of these formats, RG, is suitable as an exchange format. This paper introduces RG, describes how it is represented as an exchange format, and discusses schema conversions in RG. 1. Introduction The Bauhaus project performs research on techniques to support program understanding of legacy code and more specifically on the recovery of the system's architecture, which consists of its components, connectors, and constraints. Information about the system is exclusively extracted from the source code (often this is the only reliable source of information) in a semi-automatic way that actively involves the user of one of these environments. To model source language information, the Bauhaus tools use two representations: The InterMediate Language (IML) [1] m..